IBIS Macromodel Task Group Meeting date: 06 June 2017 Members (asterisk for those attending): ANSYS: * Dan Dvorscak * Curtis Clark Broadcom (Avago): Xingdong Dai Bob Miller Cadence Design Systems: * Ambrish Varma Brad Brim Kumar Keshavan * Ken Willis eASIC: David Banas Marc Kowalski Ericsson: Anders Ekholm GlobalFoundries: Steve Parker IBM Luis Armenta Trevor Timpane Intel: * Michael Mirmak Keysight Technologies: Fangyi Rao Radek Biernacki Ming Yan Maxim Integrated Products: Hassan Rafat Mentor, A Siemens Business: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield SiSoft: Walter Katz Todd Westerhoff * Mike LaBonte Synopsys: Rita Horner Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong The meeting was led by Arpad Muranyi. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - None. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: - Arpad: Does anyone have any comments or corrections? [none] - Mike L.: Motion to approve the minutes. - Dan: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: BIRD 166.3 draft 5 Redriver Flow: - Arpad: Last week I presented a summary of the issues. - Concluded that we had conflicting requirements for this BIRD. - We either have to compromise, or go the whole way with Fangyi's proposal for the additional IRs in Init(), or perhaps call the Init() function multiple times to create the "self response" and the "cumulative response" for the series of channels up to that point. - Walter made a proposal at the end of last week's discussion that we might document the flow for Init Only (statistical), GetWave Only (time domain), and all Dual models. - Leave the rest of the combinations undocumented. - In my email I described my feeling that this is a mild way of saying that we only support those 3 cases, and the rest is at your own risk. - We had discussed this idea earlier when we considered disallowing anything other than those 3 flow cases. There were objections to that, so I wonder how people would react to this milder form of the same thing. - We also have an issue with "8b" in this BIRD draft. - If any model in the chain doesn't have a GetWave(), then we basically fall back to using Init() functions only. - But in a time domain flow we can't guarantee that every model has Init_Returns_Impulse = true. So 8b could fail. 8b could only be guaranteed to work if all models had Init_Returns_Impulse = true. - So, I have the following questions: - Should we keep 8b and add the statement that all models must have Init_Returns_Impulse = true, or should we remove 8b completely? - Should we go with Walter's verbal proposal to only document the confirmed "no problems" cases? - I'd like to try to get some answers today so we can move on. - Mike L.: I believe the proposal is to simply describe the flow in detail for those three scenarios (All Init Only, All GetWave Only, All Dual). - It doesn't mean the other scenarios won't work. - All our tools have been simulating mixed cases, but because it's not defined fully in the spec there could be some loss of consistency. - Arpad: Yes, we have been able to simulate, but we uncovered issues with BIRD 166 when we started considering mixed scenarios. - Primary problem was that some of the deconvolution scenarios are made worse by BIRD 166. - So there are some technical challenges with adding BIRD 166. - The fundamental problem BIRD 166 is trying to address is that the redriver flow is not working when Init() functions in channel 2 do optimization. - The second channel Init() functions are not aware of the cumulative channel. - Ambrish: Before the redriver flow was ever drafted, we had already considered this scenario in the original single channel flow. - We thought about it and put it in the spec: (IBIS 6.1 pg. 178) "Note: The Rx executable model file writer should keep in mind that it is not guaranteed that the impulse response that is presented to the Rx AMI_Init function will always include the effects of the Tx filter. Therefore the Rx AMI_Init function may not be able to perform accurate optimization under all circumstances. For this reason..." - I believe we should simply carry over that warning to the redriver flow. - If your Init() optimizes, be careful because you may not be getting the IR of the entire channel. - The precedent has already been set for non-redriver cases. - Ken: Rx Init() models that don't optimize work in the current flow. - If there are multiple settings in the Rx, the user/tool can sweep them. - I don't think it's unreasonable to say automated optimization works with a GetWave() model but not necessarily with an Init() model. - Arpad: To rephrase, Ambrish is saying that the flow in the spec is correct, but it does not support optimization in the downstream Init(). - Ambrish: Yes, but it's the model's issue if it assumes it will get the IR of the entire upstream channel. - That's an assumption the model maker is making. It's then between the user and the model maker. - Arpad: If we go with your interpretation and extension of this warning statement, then we don't need BIRD 166 at all. - Ambrish: Yes, correct. - Ideally, the user seeing an Init Only Rx model should have gone back to the model maker and said, "I want an optimizing Rx, so give me a GetWave() model or something that will work with all the other models in my channel." - Instead we are trying to modify the specification to make that model work. - The original concept was that if you want a comprehensive solution use GetWave(). Use Init() for a quick and dirty approach. - Bob R.: Summarizing, we might be leaning toward rejecting BIRD 166. - We are considering the cautionary statement instead. - We have a more comprehensive proposal from Keysight that may solve it. - So we could plan to reject BIRD 166 and go toward a clarification statement. - Ambrish: The beauty of this is it's already in the spec. - We just have to copy and paste it into the redriver section. - Arpad: Ambrish, could you take the AR to write that simple editorial BIRD? - Would it have a chance to make it into 7.0? - Ambrish: Yes. - Bob: We could simply reject BIRD 166 and do nothing else. - Arpad: Can we make a that recommendation for the Open Forum now and put BIRD 166 to rest? - Ambrish: Walter, Fangyi, Radek aren't here. We should wait. - Bob: We don't have to do anything now. - We can wait for Ambrish's proposal. - Bob/Mike L.: Let's compromise and table it for now. - Arpad: I thought we could make a recommendation now. - Discussions on a technical level seem to say it's not a sufficient solution. - So this BIRD 166 will probably have to be rejected no matter what. - But I'm okay with putting it in the tabled topics for now. - Bob: Motion to table BIRD 166. - Curtis: Second. [none opposed] BIRD 158.5 - Arpad: At the last Open Forum meeting we were asked to take this up again. - What is the current status? - Bob R.: BIRD 158.5 had been formally submitted for a vote. - Michael M. then submitted some comments. - Others also weighed in. - Radek agreed with some of the suggestions. - We are waiting for a BIRD 158.6 update from Radek. - Bob R.: Motion to adjourn. - Dan: Second. - Arpad: Thank you all for joining. AR: Ambrish to prepare a BIRD draft extending the warning about optimization in Init() to the redriver flow section. ------------- Next meeting: 13 June 2017 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives